IBIS Macromodel Task Group Meeting date: 16 February 2021 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Rui Yang Luminous Computing David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted Item #8 on the Agenda, PI modeling/simulation in IBIS, and said Professor Chulsoon Huang from MS&T will present on the topic at next week's meeting. Randy said that Chulsoon and Zhiping Yang had been working on a BIRD draft and shared it with Randy and Bob. ------------- Review of ARs: - Fangyi to email his updated redriver flow BIRD draft and mention the question about whether to update the regular flows as well. - Done. - Arpad and Ambrish to suggest a better name for Use_New_Flow. - Not Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 9th meeting. Randy moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Fangyi shared his updated redriver flow BIRD draft. He noted that he had made the changes suggested at the previous meeting including Arpad's editorial suggestions. Arpad said he thought the main question remaining was whether we should extend the proposed fixes from the redriver flow to the regular flows as well. Arpad recalled that he had been in favor of doing it all at once, but Ambrish had not been so keen to tackle the regular flows. Ambrish said he had re-read the existing AMI flows in IBIS 7.0, and they are complicated with many combinations (e.g., 6a, 6b, 6c, 6d in the time-domain reference flow). He said his fear was that if we decide to tackle the regular flows it will take a lot of time to make sure they are all accurate. There are lots of details. Fangyi said that if we addressed the regular flows with the new fixes, we could remove several paragraphs regarding the cases where deconvolution might be necessary. Ambrish agreed. Fangyi said that 6a, 6b, 6c, 6d, themselves would all be gone as well, so this proposal would actually simplify the flow descriptions. Walter said his group had carefully reviewed the BIRD, and they thought we were trying to do several independent things all at once. One issue the BIRD was trying to address was eliminating the need for deconvolution. Walter said this would never be a problem in the first place if all models were Dual models. He said Init-Only models get us into the trouble with the need for deconvolution, and there's really no excuse for a model maker producing an Init-Only model. Any Init-Only model could easily provide a GetWave that applied the same equalization. Walter said the portion of this BIRD proposal dealing with deconvolution could be broken off into a separate BIRD, but he might object to that BIRD because model makers should just create GetWave in all their models. The other issue the BIRD proposal is trying to address is the redriver flow. However, Walter said the proposal is unnecessarily complicated. He said the two new columns, which take the cumulative upstream IR as input and return the IR of the equalization respectively, are unnecessary. He said BIRD166 provided a simpler approach that fixed the redriver flow and did not require modifying the footprint of AMI_Init. He noted that the new BIRD proposal does not change the function signatures per se, but it does change the IR matrix data passed into Init and would necessitate changes by EDA tools. Fangyi said the issue he had originally noted with BIRD166 was that it did not handle crosstalk properly. He said he had extended the approach to create this new proposal that does address crosstalk properly. The new columns are required additions to the original IR matrix so that the EDA tool will have the IRs of all the possible channel sections and therefore all the possible crosstalk path combinations. Walter said he thought the basic redriver flow could be handled with a simpler BIRD166 type approach, and crosstalk could be addressed as a separate BIRD. Arpad asked why we would want to separate the crosstalk flow from the base redriver flow. He said if the EDA vendor is dealing with updating their existing flows, then they need to consider crosstalk as well. Fangyi agreed and said that was why he addressed both with his proposal. Arpad again asked if we wanted to address the normal flows at this point. Fangyi said that for him it was just a question of adding a few more paragraphs, or we could separate the topics, finish the redriver flow first, and then come back to the normal flow later. Arpad said he was inclined to do it all at once. Ambrish said he was concerned that we would then be changing too many things at once. Randy asked if people wanted this BIRD to be considered for IBIS 7.1. Walter said he hadn't seen a lot of interest in redriver models, and that the big thing these days was higher speed devices like 112Gbps and 256Gbps, and the channels were short so there were no redrivers. He said this proposal would create a lot of work for EDA companies, and it was largely academic since crosstalk often wasn't important in redriver simulations. He thought there was no rush for this and said he wouldn't support putting it in 7.1. Michael M. said they did see some requests for redrivers, typically for PCIe. He said the speeds may not be 112Gbps, but they're getting up there. People are often interested in backward compatible devices and reduced cost tradeoffs between redrivers, retimers, etc. Simulation can help with tradeoff analysis. Arpad asked how close we were to being finished with this BIRD draft if we don't get involved with fixing the regular flows. Ambrish asked, aside from this BIRD how many weeks did we think we had until we decided what went into 7.1? Randy said we would be reviewing BIRD202.2 again at the next Open Forum meeting on February 19th, and we could conceivably schedule a vote on it at the following Open Forum meeting. He said anything introduced after Friday the 19th would likely affect the schedule, though we could start editorial work on things that we knew would be approved. Radek said that if we did not make the changes to address the regular flow, then he thought the BIRD draft was ready to go. Arpad agreed and said we could leave it to Fangyi. Fangyi said he was ready to submit the proposal if we decided not to address the normal flow. Arpad asked if anyone was opposed to Fangyi submitting his current proposal to the Open Forum as an official BIRD before Friday's Open Forum meeting. Walter said he was opposed, and he asked that his name be removed from the list of authors. Arpad said we would leave it up to Fangyi to decide whether or not to submit his proposal, since there's no requirement to get approval from ATM or any other task group before a person submits a BIRD. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 23 February 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives